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1 .   INTRODUCTION 

Traditionally,  medical  data  pertaining  to  individual  patients 
is  manually  processed  in  a  raw  alpha-numeric  form.   Two  types  of  problems 
are  apparent  in  this  method:   those  that  concern  management  of  the  patient 
and  those  that  concern  management  of  the  record.   The  first  type  includes 
those  problems  which  directly  affect  patient  care.   For  example,  in  a 
handwritten  record  where  entries  are  sequentially  made  by  several  indi- 
viduals, the  extraction  of  important  medical  information  is  often  difficult, 
Much  time  may  be  required  to  locate  a  specific  portion  of  the  record.   In 
addition,  the  hard  copy  record  makes  simultaneous  usage  of  the  record  by 
two  or  more  people  impractical.   Concerning  hard  copy  record  reliability, 
".  .  .at  any  given  time  about  107o  of  the  records  may  be  missing  and  about 
17o  are,  in  effect,  permanently  lost  to  the  system,  largely  due  to  mis- 
filing."   The  second  problem  type  of  the  present  system  concerns  the 
management  of  the  record.   For  example,  large  storage  areas  are  required 
which  must  be  heated,  lit  and  serviced.   The  hard  copy  record  must  be 
moved,  either  as  a  unit  or  in  sections,  from  person  to  person,  ward  to 
ward,  etc.   Clerks  and  secretaries  are  required  to  make  entries.   A 
sufficient  staff  is  required  to  provide  twenty-four  hour  medical  record 
retrieval  seven  days  per  week.   Finally,  all  the  above  items  reflect  a 
major  portion  of  record  management  cost. 

One  can  assume  that  the  primary  functions  of  any  medical  record 
include:   (1)  acting  as  the  main  vehicle  of  communication  concerning  a 
patient's  care,  (2)  acting  as  the  permanent  document  for  investigative 
procedures  and  treatments  used  to  define  and  solve  the  patient's  problems, 


(3)  aiding  the  physician's  memory  when  reviewing  a  patient's  care,  and 

(4)  serving  as  a  legal  document  concerning  a  patient's  care.   An 
examination  of  the  problems  with  current  medical  record  procedures  and 
goals  of  a  computer-based  medical  record  system  yields  some  requirements 
of  the  computer-based  medical  record  system. 

Reliability  comparable  or  superior  to  that  of  the  manual  record 
is  essential  to  the  computer-based  medical  record.   Since  identification 
of  the  user  making  entries  may  no  longer  be  reflected  in  handwriting, 
style  of  entry  or  signature,  an  identification  system  or  "signature  proxy" 
must  be  developed.   The  use  of  plastic  cards  acceptable  to  the  system  with 
name  and  identification  number  of  the  user  might  be  one  solution.   In 
addition,  the  system  should  be  capable  of  generating  a  medical  summary 
for  each  record.   Also,  the  terminals  must  be  mobile  or  sufficiently 
inexpensive  to  permit  "terminal  availability  to  follow  the  user."    Much 
time  can  be  lost  if  the  user  must  come  to  a  terminal.   Regarding  system 
performance,  visual  displays  must  be  developed  and  presented  quickly,  and 
hard  copy  capabilities  will  be  required  for  sending  records  to  areas  where 
the  system  is  unavailable.   Finally,  error  correction  should  be  made  by 
amendment  rather  than  deletion  and  insertion.   The  goal  here  is  to  provide 
legal  protection  for  each  physician  user.   A  successful  computer-based 
medical  record  system  must  provide  sufficient  flexibility  for  individual 
preferences  and  needs  and  still  consider  all  the  above  features. 

Research  in  the  area  of  computer-based  medical  record  systems 
was  initiated  by  the  medical  community's  interest  in  the  development  of 
a  Source  Oriented  Medical  Information  System  (SOMIS)  (see  figure  1.1). 
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Figure  1.1.   An  Overview  of  the  PLATO  IV-based  Problem 
Oriented  Medical  Information  System. 
Brief  Encounter  Review  Software  Resides 
Between  the  PLATO  IV  Unit  and  the  User. 


A  component  of  the  SQMIS  project  is  the  software  package  capable  of 
generating  a  current  summary  of  the  medical  record  contents.   The  function 
of  this  summary  is  to  act  as  an  interface  between  the  total  record  and  the 
user.   Summaries  are  generally  available  only  in  hospital  records  where  a 
summary  is  a  required  part  of  each  record.   Although  generally  considered 
useful,  summaries  are  usually  not  created  when  not  required  due  to  the 
time  requirement. 

Aside  from  directly  assisting  medical  care  delivery  by  improved 
data  retrieval  and  presentation,  the  collection  of  individual  patient 
records  stored  together  in  the  computer  produces  a  broad  data  base  suitable 
for  medical  research.   Because  the  computer  is  able  to  quickly  examine 
many  past  entries  concerning  a  given  test,  the  patient's  record  serves 

also  as  an  individual  data  base  which  can  be  used  to  determine  individual 

2  3 

norms. 

In  giving  consideration  to  the  development  of  a  Computer-based 
Medical  Record  Review  system,  one  can  readily  see  that  the  ability  of  a 
system  to  produce  graphic  displays  is  desirable  as  an  aid  to  the  user  in 
the  interpretation  of  the  available  data.   Examples  of  quantitative  medical 
data  which  might  best  be  described  in  graphic  form  include  pulse  rate, 
temperature,  respiratory  rate,  blood  pressure,  fluid  balance  and  laboratory 
test  results.   Departmental  reports  such  as  those  from  surgical,  renal, 

cardiac  and  intensive  care  units  may  also  be  best  represented  in  graphic 

3 
form.    Also,  qualitative  and  semiquantitative  information  as  found  in 

progress  notes  can  often  be  presented  in  graphic  form. 

The  purpose  of  this  thesis  research  is  to  consider  requirements 


and  exemplary  methods  for  displaying  machine-stored  patient  medical  data 
with  a  substantially  decreased  specific  data  access  time  over  manual 
processing  and  with  enhancement  of  meaning  of  the  alpha-numeric  data 
through  the  use  of  standard  format  and  graphics. 

In  that  the  topics  discussed  in  this  thesis  are  related  to 
output  display  of  stored  data,  the  reader  may  assume  that  all  data  used 
for  output  presentation  has  been  stored  in  computer  storage  devices 
through  source  oriented  data  collection  procedures.   Generally,  the  methods 
for  introducing  data  to  the  machine  are  not  discussed.   Discussion  of  the 
data  organization  as  it  is  presented  to  the  output  processor  is  included 
where  appropriate. 

To  aid  in  understanding  the  problems  as  well  as  the  advantages 
of  computer  processed  patient  medical  data,  many  of  the  topics  discussed 
have  been  implemented  on  an  educational  graphics  system  developed  at  the 

University  of  Illinois,  PLATO  IV.   PLATO  IV  was  selected  as  host  computer 

4 
because  of  its  extensive  graphic  capabilities.    PLATO  IV  graphics  are 

produced  at  a  rate  of  60  lines  and/or  180  characters  per  second.   Also, 

PLATO  IV  has  a  16  x  16  touch  sensitive  light  grid  over  the  display  screen 

which  permits  the  user  to  identify  an  area  on  the  screen  by  interrupting 

two  light  beams  representing  the  ordinate  and  abscissa.   This  is  especially 

useful  in  that  many  potential  users  of  a  Computer-based  Medical  Record 

Review  system  possess  limited  clerical  ability,  making  computer-user 

interaction  through  keyboard  usage  impractical.   The  reader  should  keep 

in  mind  that  computer  implementation  of  topics  presented  is  not  intended 

to  represent  a  flawless  Computer-based  Medical  Record  Review  system 


prepared  for  immediate  operation.   Rather,  PLATO  IV  is  a  laboratory  device 
used  to  examine  computer-based  medical  record  procedures  and  ideas. 


2.   MEDICAL  RECORD  REPORTING  (THE  COMPLETE  SYSTEM) 

Recent  advances  in  computer  software  and  hardware  technology 
paralled  by  the  interest  of  the  medical  community  in  the  development  of 
a  Source  Oriented  Medical  Information  System  (SOMIS)  has  set  the  stage 
for  development  of  computer-based  medical  record  systems.   Research  and 
development  in  the  area  of  Computer  Aided  Instruction  (CAI)  has  produced 
much  user  oriented  equipment.   It  is  this  equipment  which  is  often  most 
applicable  to  computer-based  medical  record  systems  in  that  user  orienta- 
tion of  the  equipment  often  yields  user  acceptance. 

Development  of  a  Computer-based  Medical  Record  Review  system  is 
here  described  in  terms  of  the  three  component  packages  which  make  up  the 
complete  system:   input  checking,  complete  record  retrieval,  and  current 
summary  generation.   Each  of  these  components  is  responsible  for  record 
presentation  in  a  specific  user  situation.   In  the  first  situation,  a 
patient  has  spent  some  time  answering  questions  asked  by  a  system  input 
package  regarding  the  patient's  medical  history,  present  condition,  etc., 
and  is  now  ready  to  leave  the  terminal.   However,  before  the  patient 
completes  the  questionnaire,  he  is  required  to  check  his  answers.   There- 
fore, the  system  produces  a  summary  of  the  information  for  the  patient  to 
approve  or  correct.   This  component  of  the  Computer-based  Medical  Record 
Review  system  will  be  called  "Patient  Error  Detection  and  Correction." 

In  a  second  situation,  a  physician  might  want  to  review  all 
available  information  concerning  his  patient.   The  system  is  required  to 
present  everything  in  this  patient's  record  from  the  general  summaries  of 
information  to  the  single  response  items,  e.g.,  the  yes-no  response  to  a 


question  entered  by  the  patient  during  the  system's  collection  of  the 
medical  history.   This  component  of  the  system  will  be  called  "Complete 
Record  Review." 

The  third  case  exists  when  a  physician  wants  to  briefly  review 
a  patient's  record  before  seeing  the  patient  in  the  clinic  or  hospital 
situation.   For  this  type  of  record  review,  the  physician  requires 
primarily  summary  information  with  more  specific  information  available 
upon  request.   The  component  which  produces  this  type  of  review  will  be 
called  "Brief  Encounter  Review." 

One  can  readily  see  that  the  Patient  Error  Detection  and 
Correction  component  is  quite  different  in  function  from  either  the 
Complete  Record  Review  or  Brief  Encounter  Review  components.   For  the 
purposes  of  the  paper,  the  Patient  Error  Detection  and  Correction  component 
will  not  be  discussed.   On  the  other  hand,  the  Complete  Record  Review  and 
Brief  Encounter  Review  are  quite  similar  in  content.   In  fact,  the  Brief 
Encounter  Review  (consisting  of  summary  type  information)  is  a  subset  of 
the  Complete  Record  Review.   The  boundaries  between  the  Complete  Record 
Review  and  Brief  Encounter  Review  are  defined  by  the  increased  detail 
available  only  in  the  Complete  Record  Review  component. 

One  could  think  of  the  Complete  Record  Review  component  as  a 
satellite  system  with  the  Brief  Encounter  Review  summaries  as  the  nucleus. 
If  each  satellite  represents  a  package  responsible  for  presenting  informa- 
tion in  some  form,  the  type  of  information  presented  by  each  package- 
satellite  as  one  moves  away  from  the  center  is  more  detailed  and  of  more 
limited  scope  than  any  other  package  which  is  closer  to  the  center. 


Therefore,  in  this  satellite  system,  specific  detail  increases  toward  the 
periphery  of  the  system. 

Because  the  Brief  Encounter  Review  is  more  narrowly  defined 
than  the  Complete  Record  Review,  the  goal  of  this  project  has  been  to 
define  the  major  sections  of  the  Brief  Encounter  Review.   Subpackages  of 
the  Brief  Encounter  Review  sections  have  also  been  defined  until  the 
excessive  detail  of  a  package  obviously  placed  it  in  the  Complete  Record 
Review  system. 
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Software  Development  and  Structure 

In  approaching  this  project,  some  assumptions  are  made.   First, 
the  assumption  is  made  that  much  standard  medical  information  can  best  be 
interpreted  if  it  is  represented  graphically.   Also,  it  is  assumed  that 
medical  care  could  profit  from  the  speed  and  efficiency  of  computer- 
assisted  record  keeping. 

With  a  potential  increase  in  medical  data  quantity,  medical 
record  complexity  and  size  will  increase.  Machine  management  of  this 
increasing  complex  and  extensive  material  may  be  desirable.   If  graphic 
representation  of  data  is  the  best  reporting  form  for  much  of  the  medical 
information  presently  recorded,  and  the  alpha-numerics  used  to  produce 
these  graphics  are  the  best  representation  of  the  required  information  for 
storage,  then  the  computer  is  a  most  suitable  medium  for  contemporary 
medical  information  storage  and  retrieval.   Only  the  computer  can  store 
the  compact  alpha-numerics  and  translate  them  into  informative  graphics 
with  sufficient  speed. 

The  goal  in  this  project  was  to  define  the  software  which  will 
upon  demand,  translate  the  patient  medical  record  which  has  been  stored 
in  alpha-numeric  form  into  appropriate,  standard  graphic  representation. 
This  software  "translator"  will  be  defined  as  a  tree  which  increases  in 
specificity  (as  defined  by  the  medical  information  it  produces)  by  level. 
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3.   THE  BRIEF  ENCOUNTER  REVIEW 

The  single  most  important  function  of  the  Brief  Encounter  Review 
system  is  the  production  of  a  current  summary  of  the  patient's  medical 
status.   The  purpose  for  having  summary  generation  capabilities  in  the 
Brief  Encounter  Review  system  is  to  provide  an  effective  interface  between 
the  detailed  record  and  the  user.   Items  which  should  be  included  in  the 
summary  are  (1)  medical  problems  with  qualifiers,  (2)  medications, 
(3)  laboratory  reports,  (4)  history  information,  and  (5)  specialty  or 
investigative  departmental  reports.   An  optional  comment  by  the  physician 
as  a  personal  reminder  made  during  the  last  patient-physician  encounter 
could  often  be  helpful.   Finally,  due  to  the  large  number  of  patients  a 
physician  sees  on  a  given  day,  it  might  be  helpful  to  include  a  personal 
comment  in  the  summary  which  would  indicate  something  about  the  patient's 
personal  life,  i.e.  patient  just  returned  from  vacation,  son  is  in  college, 
etc.   This  personal  information  may  assist  the  physician  in  conveying  to 
the  patient  his  personal  interest.   (See  figure  3.1). 

Medications  and  problems  make  up  a  major  portion  of  the  current 
medical  summary.   A  problem  is  entered  into  the  patient's  records  as  a 
descriptive  phrase  of  forty  or  less  characters  (letters,  blanks,  and 
standard  punctuation).   At  the  time  the  problem  is  entered  by  the  physician, 
the  system  assigns  a  number  to  the  problem.   This  number  is  the  next 
higher  integer  not  previously  assigned  to  a  problem.   The  problem  remains 
current  until  the  physician  changes  the  problem  status  to  noncurrent  or 
past.   Discussion  of  the  procedure  for  making  this  status  change  is  omitted 
except  to  say  that  the  change  is  initiated  by  the  physician  through  an 


12 


BRIEF  ENCOUNTER  REVIEW 
PROBLEM  LIST 


12 -Fever  of  unknown  on 

1 1 -Recurrent  d  i  arrhea 

10 -Recur rent  upper  GI  symptomatology 

9 -Recurrent  proctitis 

8  - Recurrent  con  j  unct  i  v i  1 1 s  /  u ve i  t  i  s 

7 -Recurrent  cyst  i  t i s 

5 - Psych  i  at  r l c  d  i  ffi cu 1 1  y 

4  - 1  nt  er m  i  1 1  en t  cough  (HX) 


SPECIALTY  REPORTS 


uro 1 ogy 


•lrb  report;: 

Ur  l  na.  1  Os  i  s 


MEDICATI ONS 


1 2  -Asp  inn  5  -Phenergan 

1 2 -Ch 1 ortr  i  met on 

11 -Mineral  oil 

1 1 -Lomot  i 1 

10-Tigan 


PHYSICIAN  REMINDER 


D  i  d  pat  i  ent  see  psych  i  a t  r i  st  as 
recommended? 


PERSONAL  NOTE 


[PROGRESS  Patient  returned  from 
NOTES    Carr  i  bbean  vacat  i  on  - 


(*)  MORE   9/16/73 
(CURRENT) 


I  EXIT 


HISTORIES 
Medical  history 
Social  history 
Farni  ly  history 
Genet i c  hi  st  or y 

NAME:  Doe,  John  Q. 
AGE:  3  4  ■ 


ADDRESS:  2  701  E.  Sherwin 

Urbana,  111.  61801 
LAST  I/O  DATE:  09/30/73 
PATIENT  NO:  AJ1375 


Figure  3.1.   The  Brief  Encounter  Review  Summary  Display, 
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input  function;  the  system  cannot  change  a  problem's  status.   However,  the 
system  does  assign  a  second  date  to  the  problem  when  a  current  problem 
becomes  a  past  problem.   The  problem,  its  problem  number,  date  of  onset 
and  date  of  resolution  become  a  permanent  part  of  the  complete  problem 
list  for  this  patient. 

As  long  as  the  problem  remains  current,  the  problem  with  its 
problem  number  appear  on  the  summary  (date  of  onset  is  omitted  due  to 
lack  of  available  space).   However,  the  position  of  the  problem  in  the 
problem  list  may  vary.   For  example,  the  last  (most  current)  problem 
entered  appears  at  the  top  of  the  problem  list.   Therefore,  if  a  problem 
remains  current  for  a  long  period  of  time,  the  problem  may  move  from  the 
top  to  the  bottom  of  the  list  as  more  recent  problems  are  added  to  the 
top  of  the  list.   When  a  problem  is  no  longer  current,  it  is  removed  by 
the  system  from  the  current  summary  problem  list  and  is  placed  in  the  list 
of  all  problems,  both  past  and  current,  experienced  by  the  patient.   A 
residual  or  static  problem  would  remain  current  indefinitely.   This  may  be 
sufficient  reason  for  separating  current  problems  into  active  and  inactive 
subclasses.   The  goal  of  an  updated  problem  list  is  to  provide  a  major 
component  in  the  development  of  a  health  status  index. 

Once  a  problem  is  removed  from  the  current  problem  list,  this 
problem  can  never  become  current  again.   However,  if  a  problem  of  similar 
description  to  a  now  past  problem  is  present,  a  similar  description  is 
entered  into  the  record  by  the  physician,  but  a  new  problem  number  is 
assigned.   Later  discussion  will  be  concerned  with  the  linking  of  these 
related  problems. 

The  medication  list  in  the  current  summary  is  very  similar  to 
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the  problem  list.   When  a  medication  is  prescribed,  the  medication  may 
optionally  be  assigned  the  number  of  the  problem  it  is  prescribed  to 
help.   Information  concerning  the  starting  date,  duration,  dosage  and 
other  pertinent  information  about  the  prescription  is  also  entered. 
Retrieval  of  this  related  information  will  be  discussed  in  the  section  on 
medication  information  reporting. 

A  medication  remains  on  the  current  summary  list  as  long  as  the 
medication  is  being  given.   When  the  medication  is  stopped,  it  is  taken 
off  the  current  medication  list  and  is  put  in  the  discontinued  medications 
listing  which  is  a  part  of  the  total  medication  listing.   The  discontinua- 
tion of  a  medication  can  generally  be  accomplished  in  one  of  two  ways. 
The  most  straightforward  way  to  discontinue  a  medication  is  by  having  the 
physician  directly  discontinue  a  medication  through  some  input  function. 
This  method  is  very  similar  to  the  method  used  in  changing  a  current 
problem  into  a  past  problem. 

The  second  method  for  discontinuing  a  medication  is  by  system 
action.   If  a  physician  writes  a  prescription  to  run  seven  days,  the  system 
can  calculate  when  the  eighth  day  has  been  reached,  and  in  the  absence  of 
a  renewal  order  for  this  medication,  indicate  the  medication  has  been 
stopped.   One  should  note  that  the  physician  can  over-ride  the  system 
action  in  that  he  can  indicate  that  a  medication  which  was  originally 
planned  to  continue  seven  days  has  been  discontinued  on  some  arbitrary  day 
before  the  seventh  day. 

The  name  or  description  of  a  medication  can  be  twenty  characters 
long.  This  is  generally  sufficient  length  to  handle  most  medication  names 
or  descriptions  (either  generic  or  trade  names). 
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When  a  problem  is  taken  off  the  current  problem  list,  that 
problem  with  that  problem  number  can  never  again  become  current.   However, 
in  the  medication  list,  when  a  medication  is  discontinued  and  later 
restarted,  even  though  the  medication  might  be  associated  with  a  different 
problem,  the  system  always  views  a  given  medication  as  the  same  medication. 
The  reason  for  this  is  that  although  a  patient  had  a  cold  in  January  and 
another  cold  in  March  of  the  same  year,  there  is  no  certainty  concerning 
the  etiology  of  these  colds.   On  the  other  hand,  a  medication  used  to  treat 
one  problem  and  the  same  medication  used  to  treat  a  second  problem  is  the 
same  medication.   Dosages,  durations,  problems  being  treated  by  a  medica- 
tion, and  effectiveness  may  vary,  but  the  medication  itself  is  the  same. 
The  usefulness  of  this  approach  to  problem  and  medication  reporting  will 
become  more  apparent  to  the  reader  in  subsequent  chapters. 

The  next  three  sections  of  the  current  summary  include  (1) 
specialty  reports,  (2)  laboratory  reports  and  (3)  histories.   Specialty 
reports  consist  of  a  listing  of  reports  in  the  patient's  record  which  were 
made  by  specialists  or  consultants.   When  a  new  specialty  report  is  entered 
into  the  patient  record,  the  entry  is  listed  in  the  current  summary.   This 
entry  will  remain  in  the  current  summary  as  long  as  the  physician  thinks 
it  is  pertinent  to  the  patient's  present  condition.   Therefore,  an  entry 
in  the  class  of  specialty  reports  may  remain  current  for  days  or  years. 
One  should  note  that  a  specialty  report  entry  may  once  again  become  current 
after  being  removed  from  the  current  listing. 

Laboratory  reports  are  very  similar  to  specialty  reports  in  that 
they  are  current  upon  entry.   However,  some  laboratory  reports  may  in  a 
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sense  always  be  current  because  past  results  are  used  to  establish  indi- 
vidual norms  for  a  patient.   More  discussion  about  computation  of  individual 
norms  will  follow  in  the  section  on  laboratory  result  reporting.   Those 
laboratory  reports  which  are  not  forever  current  may  be  removed  randomly 
by  the  physician  from  the  current  summary  listing  or  may  displaced. 

Histories,  like  specialty  reports,  can  remain  current  as  long  as 
needed.   Some  of  the  general  histories  include  medical  history,  personal 
history  and  genetic  history.   The  details  of  the  history  reports  will  be 
discussed  in  the  section  on  histories. 

The  last  two  sections  of  the  current  summary  are  the  physician 
reminder  and  patient  personal  note.   These  areas  serve  as  a  scratch  pad 
for  the  physician.   The  notes  placed  here  can  be  changed  as  the  physician 
wishes  but  will  remain  unchanged  permanently  in  the  absence  of  user  editing. 
Information  in  the  section  physician  reminder  will  most  often  pertain  to 
some  portion  of  the  patient's  case  where  in  the  patient  personal  note 
section,  the  information  will  be  of  a  more  socio-personal  nature  pertaining 
to  the  patient. 

Finally,  the  reader  may  have  observed  that  no  mention  has  been 
made  about  one  very  important  part  of  the  standard  medical  record--the 
progress  notes.   In  that  there  is  not  sufficient  space  on  the  summary 
display  to  produce  even  one  progress  note  in  its  entirety,  the  author  has 
chosen  to  delay  explanation  of  progress  note  representation  until  the 
discussion  of  "paging  through  the  record"  has  been  completed.   Therefore, 
an  explanation  of  how  the  user  can  manipulate  the  patient  record  is 
contained  in  the  following  chapter. 


17 


Software  Development  and  Structure 

Before  discussing  the  method  of  producing  the  summary,  some 
definitions  are  required.   First,  a  single  presentation  which  is  produced 
on  the  screen  is  called  a  "page"  or  display.   Secondly,  a  "software 
package"  is  used  to  produce  a  single  page  or  collection  of  similar  pages. 

Now,  the  summary  page  is  produced  in  three  sections.   The  rules 
used  to  construct  these  sections  are  standard  rules  used  for  all  displays 
throughout  the  system.   Therefore,  the  summary  page  will  serve  as  an  example 
for  all  displays.   The  first  section  is  responsible  for  producing  the  frame 
of  the  page.   The  frame  consists  of  all  labels,  markings  and  keys  which 
make  the  information  meaningful  (see  figure  3.2).   The  frame  is  the  most 
consistent  part  of  any  page;  it  never  changes. 

The  second  section  produces  the  patient  data  i.e.,  problems, 
medications,  histories,  etc.   The  goal  in  this  section  is  twofold.   First, 
the  display  must  appear  quickly,  and  secondly,  the  patient  information 
stored  in  the  machine  must  be  stored  compactly.   Therefore,  a  trade-off 
must  exist  between  the  activity  of  the  intelligent  component  of  the 
software  which  knows  where  and  how  to  place  all  information  in  a  display 
and  the  amount  of  type  and  display  information  which  must  be  stored  with 
the  data.   The  amount  of  activity  required  from  the  intelligent  component 
and  the  amount  of  type  and  display  information  stored  with  the  data  are 
inversely  related. 

In  its  most  ideal  from,  the  intelligent  component  acts  as  a 
total  translator.   It  selects  raw  alpha-numeric  data  from  "bins"  repre- 
senting sections  of  individual  records  stored  in  the  system  and  produces 
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Figure  3.2, 


Standard  Frames  and  Labels  Used  in  the 
Presentation  of  the  Brief  Encounter 
Review  Summary  Display. 
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Figure  3.3.   Schematic  Representation  of  Output 
Processing  with  the  Brief  Encounter 
Review  Software  Represented  as  the 
Ideal  Intelligent  Software  Component. 


meaningful  graphics  through  extensive  interpretation  (see  figure  3.3). 
However,  the  amount  of  interpretation  which  must  be  completed  by  the  intel- 
ligent component  is  directly  related  to  the  amount  of  time  required  to 
produce  a  display.   Therefore,  the  trade-off  exists  in  the  form  of  questions 
such  as  "How  fast  must  the  display  be  presented?"  and  "How  much  room  is 
available  for  storing  display  information?" 

For  the  purposes  of  this  thesis,  it  was  assumed  that  the 
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intelligent  component  of  the  software  is  extremely  limited.   Therefore, 
all  data  type  and  display  positioning  information  is  stored  with  the  data. 
One  can  readily  see  that  although  this  produces  extremely  fast  displays, 
at  some  period,  perhaps  during  input  of  data,  all  data  type  and  display 
positioning  information  must  be  determined  and  stored  with  reduction  in 
speed  of  that  component.   The  possibility  exists  that  slower  processing 
and  resultant  user  response  times  can  better  be  tolerated  by  the  user 
during  input  procedures  than  when  information  is  required  from  the  system 
during  output  procedures.   An  ideal  solution  would  be  to  develop  a  better 
balance  between  the  amount  of  data  type  and  display  position  information 
which  must  be  stored  and  the  degree  of  intelligence  required  from  the 
intelligent  component  of  the  software. 

The  third  section  of  the  software  package  activates  the  linking 
structure  which  allows  the  user  direct  access  to  other  parts  of  the  record, 
Detailed  explanation  of  this  section  is  covered  in  the  next  chapter. 

Regarding  the  current  or  noncurrent  status  of  any  entry,  this 
condition  is  indicated  by  a  single  bit  which  is  either  turned  on  (current) 
or  off  (noncurrent). 
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4.   MANIPULATION  OF  THE  RECORD 

Although  one  could  hope  that  the  current  summary  would  be 
sufficient  to  handle  most  situations  in  which  a  Brief  Encounter  Review 
type  summary  would  be  needed,  it  is  unrealistic  to  assume  that  the  user 
will  never  require  more  information  on  a  given  subject  than  what  is 
presented  in  the  summary.   In  order  to  give  the  user  additional  information, 
a  method  for  leaving  the  summary  display  and  presenting  new  information 
was  developed. 

Many  of  this  system's  potential  users  possess  limited  clerical 
ability.   Therefore,  the  use  of  a  keyboard  for  user  input  was  considered 
impractical.   Also,  in  a  graphic  display  system,  it  is  often  best  to  let 
the  user  reference  a  portion  of  the  graphic  display  in  his  input  request. 
Therefore,  the  input  method  described  in  this  chapter  permits  input 
directly  at  the  screen. 

The  PLATO  IV  terminal  has  a  touch  panel  which  frames  the  display 
screen.   The  touch  panel  produces  a  16  by  16  grid  of  infrared  light  beams 
with  a  resolution  approximately  equal  to  the  size  of  a  human  finger.   If 
the  user  touches  the  screen  and  breaks  any  single  horizontal  beam  and  any 
single  vertical  beam,  the  intersection  is  distinct,  and  the  machine  "knows" 
where  the  screen  has  been  touched.   The  PLATO  IV  touch  panel  produces  256 
distinct  intersections  which  can  individually  or  in  groups  identify  areas 
on  the  screen.   Therefore,  the  touch  panel  provides  a  way  other  than  by 
picking  up  a  light  pen  or  moving  a  cursor  from  off-screen  of  selectively 
linking  to  individual  parts  of  the  medical  record. 

The  touch  linking  mechanism  can  be  divided  into  two  distinct 
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Figure  4.1.   Standard  Touch  Selector  Including 
Identification  Box  Activator. 
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parts:   a  standard  selector  and  a  display  specific  selector.   The  standard 
selector  is  presented  at  the  bottom  of  the  display  screen  (see  figure  4.1). 
The  main  purpose  of  the  selector  which  appears  on  every  display  except  the 
summary  is  to  provide  links  to  each  of  the  major  topic  selector  pages,  i.e. 
problem,  medications,  histories,  laboratory  reports  or  specialty  reports. 
A  link  to  the  summary  page  and  a  link  to  exit  this  particular  record  are 
also  provided.   Four  special  purpose  touch  boxes  which  complete  the 
selector  will  be  discussed  later  in  this  chapter.   The  summary  display  does 
not  require  the  standard  selector.   The  reasons  for  this  will  become 
obvious  to  the  reader  later  in  this  chapter. 

The  touch  boxes  of  the  selector  are  uniquely  designed  so  that 
the  intersection  of  a  light  beam  pair  falls  in  the  center  of  each  box. 
To  accomplish  a  link  to  one  of  these  topic  selectors,  the  user  touches  the 
appropriate  box,  interrupts  the  appropriate  light  beam  pair,  and  the  system 
links  to  the  appropriate  topic  selector  and  presents  the  selector. 

In  the  case  where  no  supporting  information  is  present  when  a 
selector  box  is  touched,  the  label  in  the  box  is  erased  and  the  term  "NO 
QA.TA"  is  produced.   The  "NO  DATA"  condition  does  not  alter  the  remaining 
touch  links  or  the  current  display  (see  figure  4.2). 

The  second  group  of  touch  links  occurs  in  the  graphic  representa- 
tion of  the  medical  data.   For  the  purpose  of  this  discussion,  the  summary 
display  will  be  used  as  an  example.   Similar  links  are  provided  in  other 
displays. 

On  the  summary  display,  the  display  frames  and  labels  are 
presented  followed  by  the  graphic  representation  of  the  stored  data.   After 
the  display  is  completed,  the  system  waits  for  the  user  to  respond  by 
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Figure  4.2.   Standard  Touch  Selector  with  Null  Link  Indicated. 
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touching  the  screen  (see  figure  4.3).   If  the  user  touches  any  but  the 
bright  areas  of  figure  4.3  which  represent  touch  link  areas  when  the 
summary  page  is  presented,  no  response  is  observed.   However,  if  the  user 
touches  the  screen  anywhere  in  a  bright  area,  a  predefined  response  is 
initiated. 

If  the  bright  area  where  the  problem  list  was  presented  is 
touched,  the  machine  links  to  a  new  display  called  the  problem  list 
selector  (its  function  is  explained  in  the  chapter  on  problem  lists  and 
links).   Similarly,  if  the  user  touches  any  of  the  areas  which  represent 
the  medication  list,  history  list,  specialty  report  list,  or  laboratory 
report  list,  the  system  responds  by  locating  and  presenting  selectors  for 
the  medication,  history,  specialty  or  laboratory  reports,  respectively. 
Therefore,  the  user  can  link  to  any  one  of  five  selectors  from  the  summary 
page  which  in  turn  will  provide  him  with  more  specific  information  on  a 
given  topic.   These  links  are  similar  to  the  links  found  in  the  standard 
selector  (see  figure  4.4). 
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Figure   4.4.      Tree   Representation  of  Linking   Structure  Available 
to   the  User   from  the    Summary   Display. 
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After  the  system  has  presented  the  display  and  selector,  the 
linker  is  activated,  and  the  system  waits  for  a  user  response.   When  an 
intersection  is  interrupted,  the  system  checks  its  list  of  explicit 
instructions  for  specific  intersections.   If  the  interrupted  intersection 
is  included  in  the  list  of  explicit  instructions  for  specific  intersections, 
the  system  performs  the  associated  instructions.   If  the  intersection  is 
not  in  the  specific  intersection  list,  the  system  does  not  disturb  the 
current  display  and  again  waits  for  another  user  instruction.   Therefore, 
the  implicit  instruction  for  the  system  when  an  intersection  which  is  not 
on  the  explicit  list  is  interrupted  is  to  wait  for  a  second  user  response. 
The  system  will  repeat  this  action  until  an  input  on  the  explicit  list  is 
received. 

Four  special  boxes  are  included  in  the  standard  touch  selector. 
Two  of  these  boxes  have  predefined  functions,  and  two  have  varying  func- 
tions.  The  two  boxes  with  predefined  functions  are  responsible  for 
superimposing  two  standard  graphs.   In  graphic  displays,  it  is  often  useful 
to  display  two  graphs  on  the  same  coordinate  system  to  help  show  possible 
relationships  between  them.   This  type  of  presentation  is  accomplished  by 
the  two  selector  boxes  called  "SUPERPOSITION  STORE"  and  "SUPERPOSITION." 

When  the  user  sees  a  displayed  graph  he  would  like  to  see  with 
another  graph  in  the  record,  he  touches  the  box  labelled  "SUPERPOSITION 
STORE"  which  temporarily  stores  all  the  information  required  to  produce 
the  graph  on  the  screen.   The  user  then  locates  the  second  graph  and 
touches  "SUPERPOSITION."  The  system  then  normalizes  the  axis  of  the  second 
graph  so  that  both  graphs  may  be  produced  and  plots  both  graphs.   The  first 
graph  is  removed  from  temporary  storage. 
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This  method  of  producing  two  graphs  simultaneously  does  not 
alter  the  stored  version  of  either  graph.   When  the  user  again  requests 
either  graph  one  or  two  (the  method  of  request  will  become  evident  in 
later  chapters),  they  appear  in  unaltered  form.   The  superimposed  graph 
is  not  permanently  stored. 

The  two  boxes  which  have  no  predefined  functions,  have  their 
function  defined  specifically  for  each  display  in  which  they  are  used. 
Some  examples  appear  in  later  chapters. 

In  developing  the  summary  page  linkings,  it  was  observed  that 
people  like  to  point  to  items  while  they  are  studying  them  or  referring 
to  them.   Therefore,  if  the  problem  list,  for  example,  is  immediately 
touch  linked  to  more  detailed  information,  the  user  is  not  permitted  to 
touch  the  listing  while  referencing  the  display.   The  solution  to  this 
problem  was  to  develop  a  touch  link  which  activates  all  other  touch  links. 

On  every  page,  the  patient  identification  box  is  reproduced  to 
confirm  that  the  system  has  not  relocated  itself  in  a  different  record 
from  the  one  desired  while  searching  for  and  presenting  a  new  display. 
Since  this  box  serves  little  purpose  after  record  confirmation  is  made, 
it  was  decided  that  the  identification  box  could  become  the  touch  link 
activator. 

After  the  display  is  complete  including  selector  and  identifica- 
tion, only  the  identification  box  is  touch  sensitive.   When  the  identifi- 
cation box  is  touched,  all  appropriate  areas  in  the  display  and  in  the 
selector  become  touch  sensitive.   The  identification  box  is  no  longer  touch 
sensitive  once  it  has  been  touched.   This  touch  activation  is  required  on 
every  display  before  linking  can  be  accomplished.   Therefore,  in  the 
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following  sections  when  linking  procedures  are  being  discussed,  the 
assumption  will  be  made  that  the  identification  box  has  been  previously 
touched  and  the  touch  links  are  activated.   Touching  the  identification 
box  does  not  alter  the  current  display. 
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Software  Development  and  Structure 

One  objective  was  to  build  consistency  into  every  display.   For 
example,  every  time  the  summary  page  is  produced,  the  problem  list  and  each 
of  the  other  lists  appear  in  the  same  position  and  appear  on  the  screen 
in  the  same  order.   The  reason  for  this  attempt  at  consistency  was  twofold. 
First,  the  human  observer  quickly  adjusts  to  things  which  appear  the  same 
way  several  times.   For  example,  when  the  user  calls  for  the  current  summary 
for  his  patient,  he  is  assured  that  the  problem  list  will  always  appear 
in  the  upper  left-hand  corner  of  the  display.   Secondly,  in  order  to  set 
up  proper  touch  links,  the  author  must  know  something  about  where  certain 
items  will  appear  on  the  screen. 

If  a  touch  box  in  the  selector  always  appears  at  the  same  loca- 
tion on  the  screen,  the  user  always  knows  immediately  where  to  find  it. 
Also,  if  the  touch  box  always  appears  at  the  same  location,  a  standard 
subroutine  for  activating  the  touch  link  for  that  box  can  be  written  and 
used  whenever  that  box  is  presented  to  the  user.   In  the  case  of  the 
standard  selector  which  appears  at  the  bottom  of  the  screen  on  every  page, 
two  standard  routines  are  used.   The  first  routine  presents  the  selector 
in  standard  format.   The  second  routine  activates  all  of  the  links. 

The  routine  which  produces  the  touch  links  for  the  selector  and 
each  display  has  four  sections.   Section  one  is  responsible  for  putting 
the  machine  in  a  state  where  it  is  waiting  for  input  from  the  user. 
Section  two  contains  the  list  of  intersections  corresponding  to  the  standard 
selector  with  the  appropriate  collection  of  standard  explicit  instructions. 
The  list  of  intersections  and  instructions  appears  in  the  form  of  the 
intersection  coordinates  followed  by  the  special  instructions  to  be 
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executed  when  that  intersection  is  interrupted.   The  instructions  of  one 
group  are  followed  by  the  coordinates  of  the  next  intersection  and  its 
special  instruction  group.   This  ordering  is  repeated  until  all  desired 
intersections  are  listed.   Section  three  contains  all  coordinates  and 
instructions  for  any  links  found  in  the  display  area  and  the  variable 
function  boxes  of  the  selector.   Section  four  marks  the  end  of  the  routine. 
Section  four  also  handles  the  condition  when  a  coordinate  pair  not  explic- 
itly defined  in  sections  two  or  three  is  interrupted  by  returning  control 
to  section  one  which  returns  the  machine  to  a  waiting  state. 

Since  sections  one  and  two  are  standard,  they  are  stored  in  the 
form  of  a  macro.  To  accomplish  the  activation  of  all  links,  the  standard 
macro  is  joined  to  the  code  and  sections  three  and  four  are  appended. 

In  using  the  identification  box  as  a  touch  activator,  a  three 
section  macro  was  defined  which  first  puts  the  machine  in  a  waiting  state. 
Secondly,  the  only  coordinates  included  in  section  two  are  those  which 
are  found  in  the  identification  box.   Section  three  is  omitted  and  section 
four  responds  as  before.   The  special  instructions  for  the  intersections 
of  the  identification  box  transfer  control  to  the  standard  selector  macro 
described  above.   Therefore,  the  system  response  when  the  user  touches 
the  identification  box  is  to  activate  all  predefined  areas  of  the  display 
and  selector  (see  figure  4.5). 
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Figure  4.5.   Finite  State  Representation  of  Touch  Link  Activation. 


A  special  condition  exists  when  the  user  touches  a  box  in  the 
selector  which  is  defined  in  the  activation  list  and  directs  the  system  to 
locate  data  which  does  not  exist  in  a  particular  record.   A  special  section 
of  code  directs  the  system  to  erase  the  box  on  the  screen  which  was  touched 
by  the  user  and  write  "NO  DATA"  (see  figure  4.2).   The  main  purpose  in 
making  a  visual  response  to  the  user  rather  than  handling  the  situation 
with  no  response  is  to  confirm  for  the  user  that  the  system  has  not 
failed.   This  method  of  searching  for  data  is  extremely  important  in  that 
when  the  link  to  a  new  display  is  initiated,  the  system  searches  for  the 
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data  used  in  the  new  display  before  erasing  the  current  display.   Therefore, 
if  no  data  is  found  for  the  new  display,  the  current  display  has  not  been 
destroyed. 
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5.   PROGRESS  NOTES 

In  the  discussion  of  the  summary  information  available,  the 
topic  of  progress  notes  was  purposely  omitted.   In  that  the  summary  display 
did  not  have  sufficient  physical  space  to  produce  even  a  single  progress 
note,  separate  displays  for  progress  notes  and  linking  mechanisms  to  access 
these  displays  were  developed. 

Progress  notes  appear  as  a  textual  string  preceded  by  labels. 
The  label  consists  of  the  name  and  number  of  the  problem  which  a  note 
concerns  and  the  date  the  note  was  entered.   Progress  notes  are  individually 
subdivided  into  four  parts.   These  components  include:   (1)  Subjective 
comments  (S) ,  (2)  Objective  comments  (0),  (3)  Assessment  of  the  problem  (A) 
and  (4)  Plan  for  treating  the  problem  (P) .   Therefore,  this  approach  to 
handling  progress  notes  is  called  S.O.A.P0  and  was  developed  by  Lawrence 
Weed  as  part  of  the  Problem  Oriented  Medical  Record  System. 

A  progress  note  may  be  virtually  any  length.   Similarly,  each  of 
the  S.O.A.P.  sections  may  be  of  any  length.   In  that  progress  notes  are  a 
vital  part  of  the  medical  record,  the  author  did  not  see  fit  to  restrict 
the  number  of  characters  which  could  be  used  in  a  given  progress  note. 
(The  PLATO  IV  system  does  place  some  restrictions  here  which  will  be 
discussed  in  the  Software  Development  and  Structure  section  later  in  this 
chapter.)   However,  by  allowing  the  user  to  define  the  length  of  the  note, 
the  author  could  not  guarantee  that  a  given  progress  note  would  fit  on  one 
display  page.   The  compromise  was  to  develop  a  mechanism  for  presenting  the 
progress  note  by  sections  where  necessary. 

If  the  system  were  asked  by  the  user  to  present  a  given  progress 
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Figure  5.1.   A  Complete  Progress  Note  Presented  in  a  Single  Display, 
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note,  the  system  would  apply  its  knowledge  about  both  the  amount  of  room 
on  the  page  and  the  amount  of  room  required  by  the  note.   For  example,  if 
the  display  could  present  100  characters  and  the  note  contained  100  or  less 
characters,  the  entire  note  would  be  presented  on  one  page  (see  figure 
5.1).   If  the  progress  note  had  more  than  100  characters,  the  system  would 
begin  checking  the  S  section.   If  it  had  less  than  100  characters,  it 
would  display  it  and  check  the  0  section.   If  the  total  characters  of 
sections  S  and  0  did  not  exceed  100,  the  system  would  present  the  0  section 
after  the  S  section.   If  the  100  character  limit  had  not  yet  been  reached, 
the  system  would  add  the  number  of  characters  in  the  A  section  to  the 
total.   If  the  total  were  100  or  less,  the  A  section  would  be  displayed 
after  the  S  and  0  sections.   If  the  total  had  not  yet  reached  100,  the 
system  would  not  check  the  P  section  since  a  complete  note  total  of  more 
than  100  initiated  this  system  action. 

If,  in  the  above  example,  the  A  section  had  pushed  the  total 
over  100,  the  system  would  have  presented  only  the  S  and  0  sections.   To 
display  the  remaining  portions  of  the  progress  note,  the  two  boxes  which 
have  no  predefined  functions  are  implemented.   One  box  is  labelled  "NEXT 
PAGE."   This  box  is  used  to  page  through  the  remaining  sections  of  the 
note.   In  the  example,  with  the  S  and  0  sections  presented,  the  "NEXT  PAGE" 
box  triggers  the  system  to  check  the  length  of  the  0  and  P  sections  and 
make  appropriate  presentations  (see  figures  5.2  and  5.3). 

If  any  section  were  to  have  more  than  100  characters,  the  first 
X  sentences  which  total  less  than  100  characters  would  be  presented.   "NEXT 
PAGE"  would  present  the  remaining  text  of  that  section  and  the  following 
section  completely  if  sufficient  room  exists.   If  there  were  not  sufficient 
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room  to  present  all  of  the  next  section,  none  of  the  next  section  would  be 
displayed  until  "NEXT  PAGE"  was  triggered.   When  section  P  (or  the  last 
section  of  P)  is  presented,  the  touching  of  "NEXT  PAGE"  returns  the  display 
to  the  first  section  (Section  S)  of  the  note.   Therefore,  a  given  note  is 
circularly  linked  by  sections  (see  figure  5.4). 

Since  by  touching  the  "NEXT  PAGE"  box,  the  user  continues  to 
circle  indefinitely  through  the  note,  the  second  box  without  predefined 
function  called  "NEXT  NOTE"  is  used  here  to  exit  the  present  note  and 
access  the  next  note.   But,  what  is  the  next  note? 

The  definition  of  the  next  note  depends  on  the  context  through 
which  the  note  is  accessed.   If  the  progress  notes  are  accessed  from  the 
summary  page,  then  the  progress  notes  are  presented  in  the  reverse  order 
from  which  they  were  entered  into  the  record.   Therefore,  the  last  note 
entered  is  the  first  note  presented.   The  next  note  is  defined  as  the 
last  note  entered  before  the  note  presently  being  reviewed.   Facilities 
such  as  two-way  circular  linking  are  currently  being  designed  and  will 
permit  the  user  to  study  the  evolution  or  progress  of  a  case  or  problem. 

Since  a  progress  note  is  written  about  a  specific  problem  the 
patient  is  experiencing,  the  progress  notes  about  this  problem  can  be 
accessed  from  the  problem  selector  page  (Details  concerning  the  problem 
selector  will  be  explained  in  the  chapter  on  problem  listing).   If  a 
progress  note  pertains  to  more  than  one  problem,  the  progress  note  will  be 
accessable  from  an  equal  number  of  problem  names  in  the  problem  selector. 
When  a  progress  note  is  accessed  through  its  problem,  the  last  note  entered 
concerning  that  problem  is  displayed.   The  next  note  is  defined  as  the  last 
note  ABOUT  THIS  PROBLEM  entered  before  the  note  currently  being  presented. 
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Figure  5.4.   With  a  Hypothetical  Display  Limit  of  100  Characters, 
This  Progress  Note  Has  Character  Length  of:  "S"=180, 
"0"=90,  "A"=285  and  "P"=87  Characters.   Circular, 
Two-way  Linking  Is  Also  Indicated. 
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Since  one  often  finds  that  a  previous  problem  was  related  to  a 
more  recent  problem,  if  a  progress  note  were  accessed  through  the  more 
recent  problem,  after  these  notes  had  been  exhausted,  the  system  would 
display  the  progress  notes  pertaining  to  the  related  problem  in  a  similar 
manner. 

In  the  chapter  on  problem  listing,  a  discussion  concerning  the 
possibility  of  a  past  problem  being  related  to  a  more  current  problem  will 
be  presented.   Since  related  problems  will  be  linked  in  some  manner,  it  is 
important  that  the  progress  notes  for  all  related  problems  be  linked. 
Therefore,  when  the  system  has  exhausted  the  presentation  of  progress 
notes  about  a  given  problem,  it  will  begin  presentation  of  the  most  recent 
related  problem's  progress  notes  if  such  a  problem  exists.   For  example, 
if  the  patient  had  a  cold  on  1/1/72  and  a  second  cold  on  1/10/72  which 
developed  into  pneumonia  on  1/14/72,  the  progress  notes  for  pneumonia  would 
be  followed  by  the  progress  notes  for  the  cold  on  1/14/72  which  in  turn 
would  be  followed  by  the  notes  from  the  cold  on  1/1/72.   If  the  notes  from 
the  cold  on  1/14/72  had  been  accessed  first,  the  next  notes  to  appear  would 
be  the  notes  from  the  1/1/72  cold.   After  the  last  note  in  the  entire  list 
is  presented,  the  user  has  the  option  of  returning  to  any  of  the  selectors 
or  summary. 
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Figure  5.5.   Schematic  Representation  of  Progress  Note  Storage 
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Software  Development  and  Structure 

One  can  readily  see  that  no  matter  how  the  progress  note  section 
is  accessed,  the  next  note  is  always  a  note  which  was  entered  at  some 
previous  time.   This  suggests  that  some  form  of  modified  stack  or  last  in- 
first  out  queue  be  used  to  store  the  progress  notes. 

When  the  user  calls  the  progress  notes  from  the  summary  page,  he 
expects  to  review  the  notes  in  reverse  order  from  which  they  were  entered. 
However,  when  the  user  accesses  the  progress  note  through  a  specific 
problem,  the  user  requires  only  a  subset  of  the  progress  notes  presented 
in  the  first  case. 

To  produce  the  notes  in  the  first  case,  the  system  must  merely 
pop  the  stack  to  obtain  each  next  note.   In  the  second  case,  a  pointer 
must  be  included  with  each  note  which  points  to  the  next  progress  note 
written  about  it.   This  link  would  be  established  when  the  note  was  entered 
into  the  system.   Figure  5.5  shows  how  the  entire  list  of  progress  notes 
for  a  record  might  appear  in  memory. 

Aside  from  the  pointer,  each  progress  note  has  a  list  of  infor- 
mation about  itself  in  the  label.   This  information  includes  the  number 
and  name  of  the  problem  being  referenced  (perhaps  useful  in  establishing 
the  pointer  link),  the  number  of  characters  contained  in  the  note  and  the 
number  of  characters  in  each  of  the  S.O.A.P.  sections.   All  of  this 
information  can  be  obtained  during  input  and  used  during  output. 

Finally,  the  flow  chart  used  in  presenting  progress  notes  appears 
as  figure  5.6. 
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Figure   5.6.      Flow  Chart   for   the   Presentation  of 

Multiple    (and   Single)    Part   Progress  Notes. 
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6.   INFORMATION  RELATED  TO  THE  PROBLEM  LIST 

The  summary  page  has  room  for  up  to  fourteen  current  problems. 
One  would  think  that  this  would  generally  be  sufficient  to  handle  informa- 
tion on  even  the  severely  ill.   However,  since  the  record  contains  past 
as  well  as  current  problems,  a  method  for  producing  all  past  and  present 
problems  regardless  of  number  had  to  be  developed. 

If  the  record  being  reviewed  were  to  contain  less  than  fourteen 
current  problems,  the  problem  list  on  the  summary  page  would  appear  less 
than  full.   The  user  could  obviously  see  that  there  were  less  than  fourteen 
current  problems.   However,  if  the  record  were  to  contain  exactly  fourteen 
current  problems,  the  problem  list  on  the  summary  page  would  appear  full. 
Unfortunately,  in  this  case,  the  user  could  not  distinguish  between  a 
record  presenting  a  complete  list  of  fourteen  current  problems  and  a  record 
presenting  a  partial  list  of  fourteen  current  problems  with  more  current 
problems  yet  to  be  presented.   This  question  was  resolved  by  the  placing 
of  an  asterisk  at  the  end  of  the  topic  label  "Problem  List v"  when  more 
than  fourteen  current  problems  are  present  in  a  record.   This  method  of 
flagging  lists  of  items  longer  than  what  can  reasonably  be  presented  on  the 
summary  is  used  for  all  listings  on  the  summary  page.   A  method  for  obtaining 
the  unlisted  items  is  now  needed. 

When  a  user  wants  to  see  the  extra  current  problems  and/or 
the  complete  list  of  problems,  he  touches  (1)  the  identification  box  to 
activate  the  linking  structure,  (2)  the  box  marked  "MORE (*) (CURRENT)"  and 
(3)  the  problem  list  (see  figures  3.1  and  6.1).   This  linking  sequence 
causes  the  system  to  display  as  many  current  problems  followed  by  past 


46 


6/10/73  - 

-  1-2  -  C  - 

-  Fever-  of  l 

4/23/73  - 

■  11  -  C  - 

-  P 

ecurrent 

d i  arrhea 

1/17/7  3  - 

-  10  -  C  - 

-  P 

ecurrent 

upper-  GI  symptorno  1  ogy 

9/2  5/7  3  - 

9  -  C  - 

-  Recurrent 

proct  i  1 1 s 

9/2  5/7  3  - 

8  -  C  - 

-  Recurrent 

con  j  unct  i  v 1 1 1 s  u ve  i  t  i  s 

3/02/7  2  - 

■   7  -  C  • 

-  Recurrent 

cyst  i  t  is  (HX) 

3/0 

3/0 
3/0 

2/7  2  - 
2/7  2  - 
2/7  2  - 

5  -  C  - 

-  4  -  C  - 

-  6  ,-  P  - 

-  Psych i at ri 

-  Intermitt€ 

c  di fficulty 
»nt  cough  (HX) 

2/  i 

1 0/ 1 

3/71  - 

■   2  -  P  - 

-  D i arrhea 

9/1 

3/71  - 

-   1  -  P  - 

-  Sore  throe 

t 

• 

11  -  c 
10  -  c 


Hsp  inn 
Chlcntr  irheton 
Mineral  oi 1 
Lomot i 1 
T  l  gan 
Phenergan 


6  -  P  -  Dramami ne 
2    -  P  -  Plspirin 


PROBLEM  HISTORIES  SUPER- 


UMMflRY   LIST 


PROGRESS  MEDS 
NOTES 


EXIT     LfiB^ 


I  ORE    RGE:  3 


PECIflLTY  SUPER-   RDDRESS:  2701  E.  Sherwin 
REPORTS  POSITION         Urbana,  111.  61801 
NEXT      NEXT   .  LRST  I/O  DRTE:  09/30/7  3 
PROBS     MEDS     PftTIENT  NO:  RJ1375 


Figure  6.1.   Display  of  Complete  Listings  for  Problems  and  Medications 
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problems  as  possible  beginning  with  the  most  recent  entries.   One  of  the 
special  boxes  in  the  selector  called  "MORE  PROBS"  is  used  to  cause  the 
display  to  roll  over  ten  entries  erasing  the  top  ten  problems  and  adding 
ten  more  problems  to  the  bottom.   The  result  is  to  allow  the  user  to  page 
through  the  complete  list  of  current  and  past  problems.   Upon  reaching 
the  end  of  the  listing,  the  linking  is  circular,  and  the  beginning  is  again 
produced.  Medications  are  also  included  on  this  page  and  are  independently 
controlled  by  the  box  marked  "MORE  MEDS"  (more  detail  is  included  in  the 
chapter  on  medications). 

A  second  possible  request  the  user  may  wish  to  make  from  the 
summary  is  for  a  selector  which  would  allow  the  user  to  access  progress 
notes  about  specific  problems.   To  obtain  this  selector,  the  user  touches 
the  identification  box  on  the  summary  page  (if  not  previously  touched)  to 
activate  the  links  and  then  touches  the  problem  list.   The  system  responds 
by  producing  a  problem  selector.   This  problem  list  will  scroll  as  did  the 
complete  problem  list  (see  figure  6.2).   Similarly,  the  user  can  access 
the  problem  selector  from  the  complete  problem  list  simply  by  touching  the 
problem  listing. 

The  problem  selector  lists  all  current  problems  as  presented  in 
the  summary  when  accessed  from  the  summary  page.   The  problem  selector 
provides  up  to  two  touch  links  per  entry.   The  first  link  is  initiated 
when  the  user  touches  the  problem  name  on  the  problem  selector  page.   The 
system  responds  by  presenting  the  last  progress  note  entered  about  that 
problem.   The  user  can  then  trace  through  the  progress  notes  about  this 
problem  and  its  prior  related  problems  as  described  in  chapter  five.   The 
existence  of  the  second  link  is  dependent  on  the  existence  of  related 
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Figure  6.2.   Problem  Selector  Display  Including  Touch  Boxes 
for  Linking  to  Appropriate  Related  Problems. 
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Figure  6.3.   Display  Showing  a  Current  Problem 
and  those  Problems  Related  to  it. 
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problems  to  each  problem  listed  in  the  problem  selector. 

If  a  problem  in  the  listing  has  related  problems,  a  square 
appears  to  the  left  of  the  individual  entry.   If  the  user  touches  a 
square,  the  problems  related  to  the  problem  presented  in  the  selector 
are  presented.   Figure  6.3  shows  the  resultant  display  when  a  user 
touches  the  square  associated  with  the  entry  "recurrent  diarrhea"  in 
figure  6.2.   The  related  problems  display  is  similar  to  the  problem 
selector  in  that  touching  the  name  of  any  problem  links  the  user  to 
the  progress  notes  concerning  that  problem. 
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Figure  6.4.   Subtree  Representation  for  Accessing 

Progress  Notes  via  the  Problem  Selector. 
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In  summary,  the  user  may  obtain  a  complete  listing  of  all 
problems  in  the  record  from  the  summary  page  and  then  proceed  to  the 
problem  selector  or  go  directly  from  the  summary  to  the  problem 
selector.   From  the  problem  selector,  the  user  may  obtain  information 
in  the  form  of  a  listing  of  related  problems  to  a  given  problem  and 
then  proceed  to  the  progress  notes  or  go  directly  to  the  progress  notes 
regarding  a  problem  on  the  problem  selector  (see  figure  6.4). 
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Software  Development  and  Structure 

The  method  described  in  this  chapter  for  presenting  "More 
Current  Problems"  and/or  the  complete  list  of  current  and  past  problems 
is  used  for  all  five  listings  included  in  the  summary  page.   Further 
discussion  regarding  the  presentation  of  complete  listings  in  the 
following  chapters  is  omitted.   However,  a  special  case  exists  when 
there  are  no  current  entries  in  one  or  more  of  the  five  summary  page 
listings.   For  example,  if  there  are  no  current  problems  but  some  past 
problems  in  a  record,  the  summary  listing  for  problems  is  empty  (since 
summary  listings  present  only  current  items).   However,  in  this  case, 
a  request  for  the  complete  list  of  problems  via  the  "MORE (*) CURRENT" 
box  presents  all  past  problems.   Table  6.1  represents  the  system  re- 
sponses under  various  data  conditions  when  the  complete  lists  are 
requested. 

When  a  new  problem  is  entered,  the  user  has  the  option  of 
linking  it  to  any  related  problem  already  present  in  the  record.   The 
system  would  then  have  sufficient  information  to  link  the  new  progress 
notes  together  under  a  given  problem  and  among  related  problems. 
Therefore,  one  could  assume  that  the  problems  would  be  stored  in  a 
stack  similar  to  the  method  by  which  progress  notes  are  stored.   The 
new  problems  could  be  pushed  on  the  stack  with  pointers  linking  related 
problems. 
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USER 
REQUEST 

i   '  -■ 

WHAT  IS  THE  STATUS  OF 
THE  "CURRENT"  TOPIC  LIST 

WHAT  IS  THE  STATUS  OF 
THE  "PAST"  TOPIC  LIST 

SYSTEM 
RESPONSE 

REQUEST 
FOR  A 
TOPIC* 
SELECTOR 

NON  -  NULL 

NON  -  NULL 

PRESENT 
SELECTOR 

NON  -  NULL 

NULL 

PRESENT  + 
SELECTOR 

NULL 

NON  -  NULL 

PRESENT 
SELECTOR 

NULL 

NULL 

FLASH 
"NO  DATA" 

REQUEST 

FOR  A 

COMPLETE 

LISTING 

BY 

TOPIC* 

NON  -  NULL 

NON  -  NULL 

PRESENT 
LISTING 

NON  -  NULL 

NULL 

PRESENT 
LISTING 

NULL 

NON  -  NULL 

PRESENT 
LISTING 

NULL 

NULL 

FLASH 
"NO  DATA" 

*Topics  are  defined  as  problems,  medications,  laboratory  tests,  histories 
and  specialty/consultant  reports. 


Table  6.1.   Table  of  System  Responses  to  User 
Requests  for  Complete  Listing  or 

Selectors  by  Topic  Under  Various 
Data  Conditions. 
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7.   MEDICATION  AND  RELATED  INFORMATION 

Just  as  in  the  section  on  problems,  the  Brief  Encounter 
Review  system  provides  more  information  on  medications  than  what  appears 
on  the  summary  page.   The  medication  list  in  the  summary  has  room  for 
ten  entries.   If  more  than  ten  current  medications  are  maintained  in 
the  record,  the  summary  title  "MEDICATIONS"  appears  with  an  asterisk 
appended.   The  complete  medication  list  including  all  current  and  past 
medications  is  linked  similarly  to  the  complete  problem  list.   The  user 
touches  (1)  I.D.  box,  (2)  the  box  marked  "MORE(*)n  and  (3)  the  medica- 
tion listing  on  the  summary  page,  and  the  system  presents  the  same 
display  of  problems  and  medications  presented  when  the  problem  listing 
was  touched  instead  of  the  medications  listing  in  step  3  above.   From 
the  complete  listings  display,  the  user  can  scroll  through  both  the 
complete  listing  of  problems  or  medications  by  using  the  touch  boxes 
marked  "MORE  PROBS"  and  "MORE  MEDS" ,  respectively. 

If  the  user  requires  more  information  on  the  patient's 
medications,  the  first  item  to  appear  after  the  summary  is  the  special 
warning  page.   This  page  is  on  a  separate  level  of  the  information 
tree  for  medications  and  cannot  be  bypassed  by  the  user.   Examples  of 
a  special  warning  items  would  might  appear  on  the  warning  page  include 
allergies  to  specific  medications  or  medication  types.   To  aid  in 
attracting  the  user's  attention  the  system  flashes  the  warning 
"ALLERGY-PENICILLIN",  for  example,  repeatedly  until  the  user  touches 
the  identification  box.   The  flashing  then  ceases  with  the  complete 
warning  on  the  screen  and  all  touch  links  active  (see  figure  7.1). 
This  warning  routine  can  be  used  in  any  section  of  the  record. 
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Figure  7.1.   Warning  Page  Showing  the  Patient's 
Allergy  to  Penicillin. 
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From  the  warning  page,  the  user  can  proceed  to  the  medication 
history  graph.   This  link  is  accomplished  by  allowing  the  user  to  touch 
the  warning  page  anywhere  in  the  display  area.   Touching  "MEDS"  in  the 
selector  will  also  accomplish  this  link.   Of  course,  the  user  can  exit 
the  medication  section  by  touching  any  of  the  selectors  at  the  bottom 
of  the  page. 

The  medication  history  graph  is  designed  to  show  chronological 
relationships  among  the  various  medications  in  the  patient's  record. 
The  graph  lists  the  medications  with  the  numbers  of  the  problems  it  was 
prescribed  to  treat  along  the  right  vertical  axis  of  the  graph.  Each 
prescription  is  distinct.   The  medications  are  listed  in  reverse  order 
by  starting  date  from  the  bottom  to  top  with  the  most  recent  on  the  bottom. 
Also,  all  current  medications  are  displayed  first.   The  horizontal 
axis  represents  increasing  time  from  left  to  right.   Therefore,  this 
axis  must  float  with  time  so  that  the  right-most  point  on  the  hori- 
zontal axis  spans  6  weeks  subdivided  into  weeks  and  days.  Also,  the 
appropriate  frequency  for  each  prescription  is  given  along  the  left 
vertical  axis.   (Author's  note:   A  second  possibility  would  be  to  re- 
place the  frequency  indicator  with  a  dosage  indicator.) 

With  the  frame  for  the  graph  developed,  an  algorithm  using 
the  prescription  starting  date,  the  prescription  expiration  date  and 
"today's"  date  computes  a  bar  of  appropriate  length  and  position  to  be 
plotted  on  the  graph  for  each  medication.   The  number  of  days  plotted 
is  also  placed  in  reverse  type  in  the  left  end  of  the  respective  bars. 
An  interesting  component  of  this  graphic  representation  is  that  all 
current  medications  and  only  current  medications  extend  to  the  right 
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vertical  axis  (see  figure  7.2).   Also,  the  number  of  medications 
being  taken  by  the  patient  at  any  time  is  easily  determined. 

Throughout  this  research,  methods  for  presenting  problems 
and  medications  have  been  developed  in  parallel.   However,  one  major 
difference  exists  between  problem  and  medication  recording.   A  problem 
can  occur  only  once.   (A  reoccurrence  of  a  problem  is  assigned  a  new 
problem  number  and  therefore,  becomes  a  new  problem.)   On  the  other 
hand,  a  medication  is  always  the  same  medication.   However,  a  medica- 
tion may  be  associated  with  a  number  of  problems  (or  no  problem)  over 
a  period  of  time.   A  given  medication  will  always  appear  only  once  on 
the  medication  history  graph. 

The  medication  history  graph  presents  two  new  problems. 
Since  the  horizontal  axis  represents  a  finite  period  of  time,  a  method 
for  scrolling  the  graph  to  the  right  or  back  in  time  must  be  available. 
One  of  the  special  purpose  boxes  in  the  selector  could  be  used  to 
initiate  a  finite  right  circular  scroll  of  one  to  six  weeks. 

A  second  scrolling  technique  is  required  to  bring  more 
medications  onto  the  graph.   The  second  special  box  could  be  used  to 
move  some  number  of  medications  already  presented  off  the  bottom  of  the 
graph  and  move  more  medications  with  earlier  starting  dates  on  to  the 
top.   Therefore,  this  graph  scrolls  down  and  to  the  right. 

To  obtain  more  specific  information  about  any  medication 
currently  being  presented  on  the  graph,  the  user  must  touch  the 
appropriate  bar  after  activating  the  screen  at  the  I.D.  box.   This 
information  might  regard  prescription  dates,  dosage  changes,  amount 
patient  reported  taking,  patient  comments  about  the  drug,  etc.  (see 
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Figure  7.2o   Graphic  Representation  of  a  Patients  Medication 
History.   Overlapping  Prescriptions  and 
Prescription  Durations  are  Clearly  Represented. 
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PATIENT  COMMENTS:   The  aspirin  helped  my 
headache  but  upset  my  stomach. 


BER    PROBLEM  HISTORIES  SUPER-   NAME:  Doe,  John  Q. 
SUMMARY   LIST  STORE    AGE:  3  4 


PROGRESS  MEDS   SPECIALTY  SUPER-   ADDRESS:  2  701  E.  Sherwin 

NOTES REPORTS  POSITION         Urbana,  111.  61801 

EXIT     LABS  LAST  I/O  DATE:  09/30/73 

PATIENT  NO:  AJ1375 


Figure  7.3.   Patient  Report  for  the  Medication, 
Aspirin,  with  Tabular  Information 
in  the  Upper  Right  -  Hand  Corner. 
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0- TABLETS 


PATIENT  COMMENTS:   The  aspirin  h<_. 
headache  but  upset  my  stomach. 
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PATIENT  NO:  AJ 1375 


Figure  7.4.   Display  of  Figure  7.3  with  a  Dosage  Graph  for  the 
Medication  Replacing  the  Tabular  Data.   The  Dosage 
Graph  was  Obtained  when  the  User  Touched  the  Tabular 
Information.   The  Remaining  Display  was  Unaltered. 


61 


figure  7.3  and  7.4).   The  reader  should  note  that  the  box  in  the  upper 
right  hand  corner  of  figure  7.3  can  be  replaced  by  the  dosage  graph  in 
figure  7.4.   The  interchanging  of  the  box  and  the  graph  is  accomplished 
by  the  user  touching  the  box  or  the  graph,  whichever  is  currently 
being  displayed,   PLATO  IV  selectively  erases  what  was  previously 
written  and  writes  the  new  information  without  disturbing  the  remaining 
parts  of  the  display.   This  erase  and  write  action  can  be  repeated  any 
number  of  times  with  any  number  of  displays  of  similar  size. 
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Figure  7.5.   Subtree  Representation  for  Accessing 

Information  Regarding  Patient  Medications, 


62 


In  summary,  the  information  regarding  medications  in  a  patient 
record  is  accessed  as  the  user  moves  through  a  medication  subtree  (see 
figure  7.5).   Each  level  of  the  tree  provides  more  specific  information 
regarding  the  patient's  medication  history. 
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Software  Development  and  Structure 

In  producing  the  medication  history,  the  length  and  horizontal 
position  of  each  bar  is  computed  from  the  information  available  in  the 
prescription.   Since  the  date  the  prescription  was  started  is  always 
available,  the  system  "knows"  where  to  position  the  left  end  of  the 
bar.   If  the  date  the  prescription  is  to  stop  is  also  available,  the 
length  of  the  bar  can  be  easily  determined.   Similarly,  if  the  "to  today's 
date"  duration  of  the  prescription  is  available,  the  system  can  cal- 
culate the  position  of  the  right  end  of  the  bar.   Duration  can  also  be 

computed  by: 

Total  Amount  Given 
Duration  =  

Amount  Taken  Per  Day 

Therefore,  the  position  and  length  of  each  bar  is  easily  computed. 
However,  irregularly  given  medications  present  more  of  a  problem. 

The  label  representing  the  duration  in  days  of  a  prescription 
or  length  of  a  bar  appears  inside  the  left  end  of  each  bar  and  is  ob- 
tained from  the  system's  calculation  of  the  length  of  that  bar.   The 
user  is  assured  that  the  numerical  portion  of  the  label  will  always 
fit  inside  the  bar  since  each  day  represented  by  the  bar  can  hold  one 
digit  of  the  label. 

Since  many  standard,  hard  copy  medical  records  provide  a 
place  on  the  front  of  each  chart  for  special  warning  information,  a 
similar  warning  is  placed  at  the  front  of  the  medication  section.   The 
warning  is  flashed  by  writing  and  erasing  the  warning  phrase.   After 
the  system  has  flashed  the  warning,  it  checks  to  see  if  the  identifica- 
tion box  has  been  touched.   If  the  box  has  not  been  touched,  it  flashes 


64 


the  warning  again  and  repeats  the  check.   If  it  has  been  touched,  the 
system  writes  the  warning  on  the  page  and  waits  for  further  input  from 
the  user.   The  result  of  this  procedure  is  a  continuously  flashing 
warning  which  is  stopped  with  the  complete  warning  remaining  on  the 
screen  when  the  user  activates  the  touch  links  by  touching  the  screen. 

The  dosage  graph  which  displaces  the  box  of  information  on 
the  specific  medication  graph  is  a  smaller  version  of  any  graph.   All 
three  components;  frame,  variable  data  and  linking  mechanisms;  are 
included.   The  displacement  mechanism  involves  erasing  the  previous 
display  and  producing  the  new  display.   This  procedure  is  the  same  as 
used  for  all  other  graphic  displays  except  the  area  in  which  the  new 
display  will  be  placed  is  erased  first. 
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8.   LABORATORY  RESULT  REPORTING 

As  a  representative  of  the  reports  available  from  investigative 
departments,  laboratory  reports  constitute  an  important  part  of  the 
medical  record.   Although  the  summary  provides  the  user  with  a  listing 
of  those  laboratory  reports  available  in  a  given  record,  this  listing 
tells  the  user  nothing  about  the  content  of  each  report.   The  Brief 
Encounter  Review  system  must  therefore  provide  a  link  to  a  selector 
from  which  the  user  can  select  the  report  he  is  interested  in  reviewing. 
This  link  is  accomplished  when  the  user  touches  the  listing  of  laboratory 
reports  in  the  summary  (see  figure  8.1). 

The  laboratory  report  selector  presents  a  listing  of  all 
available  laboratory  reports.   In  order  to  handle  a  listing  with  more 
entries  than  will  fit  on  a  single  display,  the  vertical  scrolling 
techniques  described  in  previous  chapters  may  be  required.   From  the 
selector,  the  user  may  begin  his  review  of  individual  reports  by 
touching  the  appropriate  entry.   The  system  responds  to  this  action  by 
locating  and  presenting  information  available  in  that  report.   Facilities 
are  currently  being  developed  which  will  flag  reports  listed  in  the 
summary  which  have  abnormal  results.  Also,  conclusion  and  interpretation 
reports  on  certain  tests  or  test  collections  will  soon  be  available. 

Often  a  laboratory  report  will  consist  of  many  individual  test 
results  which,  when  reviewed  together,  determine  the  information  in  the 
report.   Also,  many  of  the  reports  contain  test  results  which  can  best 
be  described  in  graphic  form.   Therefore,  one  type  of  laboratory 
reporting  display  is  developed  as  a  collection  of  normalized  graphs 
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Figure  8.1.   Laboratory  Report  Selector. 
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where  each  represents  a  specific  test  (see  figure  8.2). 

In  determining  the  results  of  a  blood  chemistry  report,  the 
physician  compares  the  individual  test  results  to  the  population 
standard  for  healthy  people  in  the  same  general  class  as  the  patient, 
i.e.,  sex,  race,  environment,  etc.   Therefore,  the  test  results  are 
graphically  displayed  over  a  dot  density  display.   The  center  or  most 
dense  area  on  the  graph  represents  the  normal  range  of  values  for  that 
test  as  determined  by  the  general  population.   From  observing  the 
position  of  the  marker  representing  the  test  result  with  respect  to  the 
density,  the  user  can  determine  the  amount  of  deviation  in  this  test 
result  from  what  is  considered  normal  in  the  population.   However, 
although  the  result  on  a  test  for  an  individual  may  fall  outside  the 
normal  range  of  values  for  that  test  as  determined  by  the  population, 
this  result  may  not  be  abnormal  for  this  specific  patient. 

One  method  for  determining  the  normal  results  on  a  test  for 
a  given  individual  is  to  repeat  the  test  over  a  period  of  time  while 
the  patient  is  in  a  healthy  state.   One  can  readily  see  that  this  is 
impractical  in  that  it  would  require  substantial  expense  on  the  part  of 
the  patient  and  increase  an  already  present  overload  in  the  clinics. 
Therefore,  an  alternative  method  is  to  collect  the  data  on  individual 
tests  for  the  patient  as  they  are  normally  run.   Over  a  period  of  time, 
sufficient  data  will  develop  for  some  tests  to  permit  evaluation  of  a 
new  test  result  with  respect  to  the  past  test  results.   But,  until 
sufficient  data  has  been  collected,  the  display  reporting  test  results 
must  provide  both  information  on  the  population  standards  and  as  much 
information  as  possible  on  the  individual  patient's  standards. 
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Figure  8.2.   Normalized  Graphic  Report  of  Six  Blood  Chemistry  Tests 
Taken  From  an  SMA  -  12/60.   Population  Standard  and 
Individual  Patterns  are  Indicated  for  Each  Test. 
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Figure  8.2  is  an  example  of  how  the  Brief  Encounter  Review 
laboratory  reporting  page  might  be  developed.   There  are  twelve 
standard  tests  in  the  blood  chemistry  report.   Therefore,  section  one 
represents  one  half  the  total.   Each  graph  is  labelled  and  scaled  so 
that  the  range  of  normal  values  falls  in  the  center  of  the  dot  density. 
Since  the  lower  bound  for  the  tests  in  figure  8.2  is  zero,  no  under- 
flow for  values  in  these  tests  is  possible.   However,  the  case  of  overflow 
is  not  ruled  out.   The  box  on  the  right  contains  entries  representing 
results  which  have  exceeded  the  upper  bound  of  the  scale. 

The  small  oblong  circles  represent  past  test  results  for  the 
patient.   Since  it  is  hoped  that  the  small  markers  will  cluster  and 
represent  the  normal  value  for  the  patient,  the  indicator  "N  =  #" 
specifies  the  number  of  entries  displayed.   This  is  especially  useful 
where  many  entries  appear  in  the  same  location  and  their  number  is 
unclear.   The  current  or  most  recent  test  results  appear  as  an  hourglass 
(on  its  side)  with  the  result  of  the  test  found  at  the  intersection  of 
the  glass.   The  hourglasses  come  in  five  sizes  and  are  used  to  represent 
the  analytical  variation  in  each  test  (see  figure  8.3). 

In  summary,  the  reports  of  any  laboratory  work  which  consist 
of  numerous  individual  tests  can  be  displayed  as  a  collection  of  graphs 
displayed  on  a  dot  density  field  with  the  dense  center  area  representing 
the  population  standards  for  the  tests.   The  plotting  of  past  results 
for  each  test  when  statistically  significant,  can  be  used  to  represent 
an  individual  standard  for  that  test.   Labels,  units,  scale  and  overflow 
are  all  presented  by  the  display.   Finally,  the  analytical  variation 
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Figure  8.3.   Various  Symbol  Sizes  Used  in  the  Blood 

Chemistry  Display  to  Indicate  Analytical 
Variation  Inherent  in  Each  Laboratory  Test, 
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in  each  test  is  reflected  in  the  length  of  the  hourglass  marker  of 
current  results. 

Although  the  graph  collection  provides  information  concerning 
the  value  of  the  current  tests  with  respect  to  the  population  and 
individual  standards,  one  cannot  always  determine  the  exact  value  of 
any  single  test  result  or  determine  in  what  order  a  series  of  past 
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results  for  a  given  test  were  completed.   Therefore,  the  user  is 
permitted  to  touch  the  name  of  the  test  on  the  graph  collection  for 
which  he  requires  more  detailed  information,  and  the  system  responds  by 
providing  a  standard  graph  of  results  for  that  test  with  respect  to 
time  (see  figure  8.4).   Since  these  graphs  are  in  standard  form  (as 
defined  by  the  system),  superposition  of  these  graphs  with  other  stand- 
ard graphs  is  possible. 

The  system  subtree  used  for  laboratory  results  reporting  is 
included  as  figure  8.5. 

When  the  user  requests  more  specific  information  regarding 
results  for  a  laboratory  test  the  system  determines  the  dates  of  the 
earliest  and  last  entries  and  scales  the  abscissa  appropriately.  All 
values  for  the  test  can  then  be  plotted  on  the  graph. 
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Software  Development  and  Structure 

Many  problems  are  inherent  to  presenting  a  graph  collection 
which  is  normalized  to  an  arbitrary  area  on  the  scale.   For  the  tests 
used  in  figure  8.2  the  possibility  of  underflow  was  not  present,  but 
in  other  such  reports,  the  problem  could  easily  exist.   Similarly,  by 
normalizing  the  scales  to  permit  the  normal  range  to  fall  in  the  center 
of  the  scale,  the  left  and  right  bounds  are  equidistant  and  the 
numerical  span  from  zero  to  the  center  must  equal  in  magnitude  the  span 
from  the  center  to  the  right  bound.   Therefore,  cases  of  graph  overflow 
may  be  quite  frequent. 

The  problem  with  using  a  specific  hourglass  with  a  certain 
test  report  is  not  a  real  problem  in  that  the  hourglass  selected  for  a 
test  report  is  always  used  in  reporting  that  test.   However,  plotting 
the  hourglass  figure  presents  a  more  significant  problem.   Since  the 
hourglass  characters  are  plotted  on  the  graph  from  the  left  edge  and 
the  centers  of  the  characters  are  the  markers  used  in  interpretation, 
conversion  algorithms  used  to  map  the  characters  to  the  left  a  distance 
dependent  on  the  size  of  the  character  were  developed. 

In  the  presentation  of  the  graph  collection  display,  the  dot 
density  is  produced  first.   Therefore,  when  the  oblong  circle  and 
hourglass  characters  are  marked  on  the  scale,  the  inside  of  each 
character  must  first  be  cleared  of  the  dot  density  before  the  frame  of 
the  character  is  presented.   If  the  inside  of  each  character  is  not 
erased,  the  characters  are  lost  in  the  density.   The  result  of  this 
required  operation  is  increased  presentation  time  and  greater  complexity 
for  each  character. 
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9.   HISTORIES 

In  this  chapter,  methods  for  presenting  one  type  of  history 
information  will  be  discussed.   The  linking  structures  and  presentation 
formats  presented  in  earlier  chapters  will  be  used  to  maintain  conventions 
previously  standardized  (figure  9.1). 

The  summary  display  contains  a  listing  of  history  information 
available  in  the  record.   This  listing,  as  all  other  listings  in  the  sum- 
mary, is  touch  linked  to  a  selector  from  which  the  user  can  choose  the 
report  he  is  interested  in  reviewing  (see  figure  9.2). 

When  the  user  touches  an  item  in  the  selector,  the  system  may 
present  the  information  in  that  history  record  or  present  a  subselector. 
For  example,  if  the  user  indicates  he  wishes  to  review  the  patient's  genetic 
history,  the  system  will  present  a  second  selector  in  the  form  of  a  list 
of  topics  the  patient  previously  indicated  had  a  family  history  (see 
figure  9.3).   From  this  selector  the  user  may  obtain  specific  information 
about  any  of  the  topics  listed.   (The  reader  should  note  that  all  selectors 
in  this  section  scroll  to  present  additional  entries  if  required.) 

Genetic  histories  are  best  reported  in  the  form  of  modified 
trees  where  the  patient  is  represented  by  the  root  or  top  node.   The 
patient's  sisters  and  brothers  are  indicated  to  the  left  and  right  of  the 
patient's  node,  respectively.   Since  the  sisters  are  to  the  left  of  the 
patient  node,  the  patient's  mother  is  represented  by  the  left  branch 
node.   The  patient's  maternal  aunts  and  uncles  are  located  to  the  left 
and  right  of  the  patient's  mother's  node,  respectively.   The  patient's 
father  is  represented  by  the  right  branch  node.   The  patient's  paternal 
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Figure  9.3.   Genetic  Tree  Representation  of 
Patient's  Family  with  Those  Who 
Complain  of  Headaches  Indicated, 
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aunts  and  uncles  are  positioned  to  the  left  and  right  of  this  node, 
respectively.   The  grandparents  are  placed  under  each  parent  with  the 
grandmother  to  the  left  and  grandfather  to  the  right.   For  consistency, 
the  female  entries  are  always  placed  to  the  left  of  any  major  node. 
Similarly,  the  males  are  to  the  right  (see  figure  9.3). 

Positive  responses  (the  patient  indicated  this  individual  has 
complained  of  the  problem)  are  indicated  by  an  "X"  marked  through  the  box. 
In  figure  9.3,  the  patient,  one  of  his  sisters  and  his  mother  have 
complained  of  headaches. 

The  number  of  sibling  boxes  is  arbitrary.   If  the  patient  or 
his  parents  had  more  than  three  brothers  or  sisters  each  of  which  had  a 
positive  response  to  a  given  condition,  the  marking  of  all  three  boxes 
would  give  sufficient  indication  that  a  genetic  link  might  be  investigated. 
Also,  the  tree  does  not  trace  back  farther  than  the  grandparents  because 
information  about  great  grandparents  and  the  like  is  often  unreliable. 
A  modification  might  be  to  include  a  response  for  other  relatives,  i.e 
cousins,  etc. 
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Software  Development  and  Structure 

Since  the  genetic  tree  is  a  standard  frame  produced  by  the 
system,  the  system  must  only  store  a  binary  yes-no  response  for  each 
tree  and  each  person  represented  in  the  tree.   Therefore,  this  type  of 
display  is  efficient  in  the  amount  of  computer  storage  space  required. 

The  linking  structure  from  the  summary  to  the  genetic  trees  is 
presented  as  figure  9.4. 
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10.   ODDS  AND  ENDS 

The  final  listing  to  be  covered  in  the  summary  page  is  the 
specialty  reports.   These  reports  would  be  typically  from  consultants 
or  specialists.   Most  often,  these  reports  would  be  in  standard  report 
form.   Therefore,  these  reports  would  be  reported  in  the  Brief  Encounter 
Review  in  a  manner  similar  to  that  used  for  progress  notes.   This 
would  allow  for  paging  through  a  report  in  a  manner  similar  to  that 
used  for  progress  notes. 

In  the  section  on  laboratory  reports,  the  discussion  of  how 
the  Brief  Encounter  Review  would  reproduce  pictorial  reports  such  as 
x-rays  was  omitted.   Aside  from  PLATO  IV1 s  ability  to  produce  complex 
graphics,  PLATO  IV  can  project  slides  onto  the  screen  through  the  use  of 
rear  projection  techniques.   Slides  for  PLATO  IV  are  produced  in  the 
form  of  a  micro-fiche.   The  user  could  be  required  to  select  a  patient's 
micro-fiche  when  he  prepares  to  review  the  patient's  record.   Sign  on 
procedures  would  have  the  user  insert  the  appropriate  micro-fiche 
into  the  terminal  before  reviewing  some  portions  of  the  patient's 
record. 
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11.   SUMMARY  AND  CONCLUSIONS 

A  major  function  of  the  Brief  Encounter  Review  system  is  to 
present  a  current  summary  of  the  data  contained  in  a  patient  medical 
record.   Each  summary  is  to  act  as  an  interface  between  the  detailed 
medical  record  and  the  user.   Each  summary  contains  content  lists  for 
each  of  the  five  major  medical  record  subsets:   problems,  medications, 
histories,  laboratory  results  and  specialty/consultant  reports. 
"Scratch  Pad"  areas  for  physician  use,  patient  identification  infor- 
mation and  a  link  to  the  progress  note  section  are  also  provided. 

Although  the  summary  information  should  be  sufficient  to  provide 
the  user  with  an  overview  of  the  patient's  condition,  more  detailed  in- 
formation may  be  required.   To  access  the  more  detailed  information 
contained  in  a  record,  the  user  must  activate  all  touch  links  available 
in  a  display  by  first  touching  the  I.D.  box.   The  user  may  then  select 
the  topic  (problems,  medications,  etc.)  about  which  he  requires  more 
detailed  information.   The  Brief  Encounter  Review  system  is  structured 
as  a  "by-level"  tree  with  each  level  providing  more  specifically  detailed 
information  about  the  topic  associated  with  that  branch.   Equally  as 
important  as  the  tree  structure  is  the  complex  linking  structure  de- 
veloped for  the  Brief  Encounter  Review  system.   The  linking  structure 
provides  the  user  with  extensive  record  manipulation  capabilities  without 
the  need  for  keyboard  entry  (see  figure  11.1). 

Building  consistency  into  each  display  has  been  a  primary  goal. 
All  displays  appear  on  the  screen  in  the  same  order.   Display  frames  and 
labels  appear  first  providing  display  orientation  to  the  user.   The  graphic 
representation  of  the  medical  information  is  presented  next.   Finally, 
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An  Overview  of   the   Brief  Encounter  Review 
System  with  the  Linking   Structure   Indicated. 
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appropriate  linking  structures  are  activated.   The  display  then  "waits" 
for  a  user  request  (a  touch).   Display  consistency  is  intended  to  aid 
the  user  in  becoming  familiar  with  the  Brief  Encounter  Review  content. 

The  degree  of  success  obtained  by  this  work  can  best  be 
measured  by  the  medical  community's  enthusiasm  regarding  each  of  the 
individual  displays  and  complete  prototype  system.   During  the  develop- 
ment of  the  Brief  Encounter  Review  system,  members  of  the  medical 
community  have  been  invited  to  comment  on  the  work  and  to  suggest  modi- 
fications and  additions  to  components  being  developed.   Although  the 
Brief  Encounter  Review  is  continually  being  modified  and  expanded,  on 
June  30,  1974,  a  Model  Family  Practice  Center  is  scheduled  to  begin 
operation  in  Danville,  Illinois.   Staffed  by  two  experienced  physicians, 
the  center  will  use  the  Brief  Encounter  Review  system  together  with 
other  software  packages  to  manage  medical  records  on  a  PLATO  IV-based 
Problem  Oriented  Medical  Record  System  (PROMTS) . 
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